解决2000年问题的“年份加模法”

解决2000年问题从理论上讲并不复杂。从本源上来说解决2000年问题，依据产生它的根源，只要将硬件系统和软件系统中涉及到的年份之处全部改为四位数字表示，问题就化为乌有了。然而具体操作起来工作量之巨大，谈何容易。况且用四位数字表示年份也背离了人们习以为常的用两位数字表示年份的传统习惯。

于是国外有些计算机公司提出了沿用两位数字表示年份的传统习惯，并以此为出发点，推出了解决2000年问题的方法，如：日期重译法、日期操纵法等等。但这些方法要么没有从根本上解决问题，要么将问题推迟到若干年后发生再解决。而且这些方法在修改原代码的具体操作上也带来繁琐和不便。

笔者在此以银行储蓄为背景提出解决2000年问题的“年份加模法”（或称为“年份求补法”）。该方法简便有效，便于理解，对硬件系统和软件系统（如：操作系统、数据库管理系统）无需任何改动，仍保持目前的现状和原貌，只要对应用软件中（用户的应用程序）有关的年份比较之处做些修改，就能解决2000年问题。而且凡是跨世纪的同类问题也迎刃而解。

为了说清问题，现举个日常生活的例子。我们都知道当钟表停摆，要调整到准确时间，有两种拨时针的方法，一是正拨（顺时针），另一是倒拨（逆时针），都可达到目的。正拨X小时，倒拨Y小时，两者之和为X十Y＝12小时，于是我们把12称为钟表的模。换言之，每当时钟走到12点就又从0开始计时了，即把模12丢弃了。如果我们称正拨X小时为原码，那么倒拨Y小时被称为X的以12为模的补码。举个实例来说：4和8之和为12，若称4为原码，则8为4的以12为模的补码；反之亦然。

回过头来再看1998年，当时间再过两年就是2000年了，用两位数字表示年份，即从98年到00年，同样将100这个模丢弃了，因而造成存款年份为1998年，取款年份为2000年，引发实际的存款时间为“00－98＝－98”，出现实际存款时间为－98年的现象。同钟表类似“98＋2＝100”，其中将98看成原码，2就是98的以100为模的补码了。到此为止我们已经有了原码、补码和模的概念了。

现在回到实际中来，既然从1998年到2000年用两位数字表示年份，模100丢弃了，读者自然会想到：把这个模100添上问题不就解决了吗？的确如此，然而还应注意到，如果有的储户在1998年或1999年存款，有的储户在2000年或2000年以后的年份存款，这就要区别对待，不可一概而论了。凡是存、取款年份跨世纪的都要加上模100；没有跨世纪的，即存、取款年份在同一世纪中的就不能加上模100了。

所以用于解决2000年问题或广义地说用于解决跨世纪问题的主导思想应是：如果（取款年份—存款年份）＞0，不加上模100，否则加上模100。这种算法思想用任何一种编程语言实现都是不困难的。

到此解决2000年问题的思想和算法思想清晰了。编程人员只要对现有的应用软件中有关年份比较之处做一些小修改，人们仍可沿用两位数字表示年份的习惯，操作计算机仍同以前一样，就会安全过渡到21世纪。

细心的读者可能会发现如果一个储户存款年份为1998年而取款年份为2098年，实际存款时间的年数为“98－98＝0”年，依照上面的算法思想是不应该加上模100的，这就不正确了。确实如此，不过根据银行储蓄部门的有关规定，实际存款时间的年数超过几十年（不会长达100年的），这类储户就会成为睡眠户，被放置另册单独保管了。所以这种情况仍可完美无缺地解决。